IBIS Macromodel Task Group Meeting date: 17 February 2015 Members (asterisk for those attending): Altera: David Banas ANSYS: * Dan Dvorscak Curtis Clark Avago (LSI) Xingdong Dai Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy eASIC Marc Kowalski SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Arpad: We need to discuss ground issues in the IBIS specification. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Michael M send BIRD proposal to Mike L for posting. - Sent today. - Mike L post link to Randy's presentation. - Done (just now). - Arpad to review IBIS specification for min max issues. - In progress. ------------- New Discussion: C_comp enhancements: - Michael M showed IBIS-AMI and Direction Indication. - Michael M: There is an enable function in 3-state and I/O buffers. - If I have a bidirectional analog model the algorithmic model. should have all that is needed for both directions. - Ambrish: If an I/O is present it can have only RX capability? - Michael M: It has to present the right data for the state it is in. - Two Reserved_Parameters are proposed: - AMI_Model_Type - AM_Model_Direction - Bob: 3-state has two modes, driving and high-Z. - Michael M: the high-Z mode is covered by AMI_Model_Direction Ignore. - There are 3 ways to support this: - A single DLL handles all modes. - Multiple [Algorithmic Model] sections within a [Model]. - [Algorithmic Model Selector] within a [Model]. - Arpad: Would #1 require a selector of some sort? - Michael M: All parameters would be passed, the DLL would adjudicate. - This could be tricky to program. - It might not be a viable or complete proposal. - Radek: It would need to have two controls, enable and direction. - Arpad: We could solve that with something like the way Corner works. - Michael M: It is assumed AMI_Model_Type is checked against the Model_type. - Model_Direction should be set consistently. - John: We already have the disadvantage of checking that. - The specification doesn't have a table for that. - Michael M: Options 2 and 3 change one sentence in the specification. - For option 2 we would have to allow [Algorithmic Model] more than once. - We would need a subparam too. - Existing models would not have to change. - Bob: Would this be appropriate for I/O models? - Michael M: There is a risk of using a TX DLL with an RX analog model. - Ambrish: Direction would be in the [Algorithmic Model] for cross checking? - Michael M: That would be needed for option 1. - There is a question of how many [Algorithmic Model] sections to allow. - Arpad: We should disallow having 2 of the same direction. - Radek: Agree. - [Model Selector] might map to [Models] of different directions though. - Ambrish: What is the advantage of multiple TX models? - Michael M: Without a selector it's clear. - John: For 3-state you only have TX, nothing else. - Arpad: Some would like Terminators for off state. - Michael M: That is restricted now. - Radek: Why did we disallow that? - Arpad: It makes no measurements. - John: Maybe we need a separate analog model for high-Z state. - Michael M: [Algorithmic Model Selector] would be between [Model] and [Algorithmic Model] - We now can have families of models. - This would require names for [Algorithmic Model]s. - The tool could find TX models and offer them to the user. - Arpad: - Alternatively the Executable lines could be grouped. - Michael M: - That might be less readable. - Mike L: The [Algorithmic Model]s could be named after directions instead of arbitrary names. - Michael M: That collapses into option 2. - Arpad: There could be separate groups of Executable lines. - Radek: The Executable lines could have an extra field. - Michael M: That would work as long as we would not need more fields. - Arpad: I had a group name keyword in mind. - Ambrish: We could remove one of the [Algorithmic Model Selector] columns shown. - Mike L: Do we need to allow multiple models of the same type? - Michael M: It might be used for extra corners, for example. - Ambrish: The user will have to decide which to use. - Michael M: There could be a conventiona that the "first in the list" is default. - Ambrish: Would option 2 allow for option 3 later? - Michael M: It might paint us into a corner. - John: 3 could be used with 2 if you want multiple models of the same type. - Michael M: There could be one analog model with different algorithmic models. - This could be done with [Model Selector] by repetition. - John: Protocols can be specified in the AMI file. - Radek: We should separate directionality from model selection. - Arpad: Should we move [Algorithmic Model] to component level? - Michael M: Directionality can be separate, it doesn't depend on hierarchy. - Arpad: Would option 2 preclude an I/O model? - Michael M: No, bu the tool will have to let the user choose direction. - Ambrish: Should we use Output and Input instead of TX and RX? - Michael M: I will add options 2a and 2b. - The table Radek asked for exists. - Mike: L: I'm seeing TX and RX models shipped separately. - There might not be much demand for putting many models in one IBIS file. - Michael M: This relates to BIRD 161, about IBIS files for buffers, not parts. AR: Michael M update IBIS-AMI Direction proposal ------------- Next meeting: 24 Feb 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives